home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Arsenal Files 1
/
The Arsenal Files (Arsenal Computer).ISO
/
novell
/
winup9.exe
/
DEADLOCK.TXT
< prev
next >
Wrap
Text File
|
1993-12-21
|
18KB
|
460 lines
NOVELL TECHNICAL INFORMATION DOCUMENT
TITLE: Deadlocks with Novell NetWare and Windows
NOVELL PRODUCT and VERSION: NetWare Client for DOS/Windows
ABSTRACT:
These files fix a problem when using Windows or Windows for
WorkGroups on a Novell network. The symptom is a blank screen
with a blinking underline curser in the upper-left-hand corner
of the screen and the workstation hangs.
_________________________________________________________________
DISCLAIMER
THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO
NOVELL. NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS
INFORMATION. HOWEVER, THE INFORMATION PROVIDED IN THIS DOCUMENT IS
FOR YOUR INFORMATION ONLY. NOVELL MAKES NO EXPLICIT OR IMPLIED
CLAIMS TO THE VALIDITY OF THIS INFORMATION.
_________________________________________________________________
ADDITIONAL CONFIGURATION
Third-Party Product and Version:
Windows
Windows for WorkGroups
SYMPTOM
The symptom is a blank screen with a blinking underline curser
in the upper-left-hand corner of the screen and the workstation
hangs. This may happen at any time while in Windows, launching
a dos box, using a Windows application or exiting Windows.
The following is a list of causes/solutions that Novell has
isolated that can cause/remedy the symptom described above.
CAUSE
IPXODI.COM had a bug in SPX. During a retry, SPX would jump to
invalid memory causing an invalid opcode exception in v86 mode only
when SPX is being used. Few applications use SPX. This usually
manifests itself as a reboot, hung machine, or blank screen with
cursor in upper-left corner.
CAUSE
LSL.COM had a bug that was GetStackECBPrescanIsPresent destroyed
the return Flag when an ECB was given. The symptom of this problem
would most likely manifest it self by a workstation hang when using
a protocol stack that expects to get an ECB from the LSL under a
heavy load.
CAUSE
LSL.COM also had a problem with the "Do Send for Windows" code that
needed a "Start and End Critical Section" call added.
CAUSE
An incorrect system configuration including memory management.
CAUSE
Any I/O, memory, or IRQ conflicts may cause this problem.
CAUSE
Using third-party device drivers or terminate-and-stay-resident
(TSR) programs.
CAUSE
Lan Card MLID driver's misuse of ECB buffers.
CAUSE
Third party protocol stacks, such as TCPIP.
CAUSE
VIPX.386 is a Windows 3.X virtualization driver for IPXODI.COM
driver that was enhanced jointly by Novell and Microsoft. It
virtualizes requests to the globally loaded IPX driver. When a
request is made to IPX, VIPX will allocate a request buffer in the
system's global memory, copy the original request to the global
buffer and give the global request to IPX. When the global request
completes, IPX will call VIPX. VIPX will then copy any results
back to the original request buffer and call the application that
submitted the request.
CAUSE
Some Windows applications have been found to create the symptom if when
exiting Windows the application is running in the background in a
minimized state. If this occurs, close all applications before
leaving Windows.
CAUSE
There are occasions when using a Winstart.bat file (which is created
by the user and placed in the Windows directory) may also cause Windows
to hang when exiting Windows. Avoid a Winstart.bat file if the symptom
persists.
CAUSE
Microsoft has a patch called VTDA.386 for their Windows 3.1 VTD driver.
VTDA.386 obtainable from Microsoft. Their BBS number is 206-936-6735
and the file to down load is WW0863.EXE.
Version Compatibility with Dedicated IPX
----------------------------------------
Novell officially ceased maintenance on the dedicated IPX driver
(IPX.OBJ) version 3.10 dated 11-21-91. The last version of VIPX to
explicitly support that driver is 1.10. The current version of
VIPX supports IPXODI.COM only.
Packet Size Limitations
-----------------------
VIPX.386 will only virtualize packets that are 8000 (decimal) bytes
or less. Any DOS and Windows IPX or SPX applications that use
networks with a physical packet size greater than 8000 bytes may
not work with VIPX.386. For example, IBM Token Ring can be
configured to run with 16 KB packets. A request by a DOS or
Windows IPX application to send a 16 KB packet will be truncated to
8000 bytes. On the other hand, any 16 KB packet that is received
by the LAN driver will be dropped because VIPX cannot allocate a
packet big enough to handle it.
Memory Manager Limitations
--------------------------
When a request is passed up from IPX, VIPX will immediately test
the request buffer to see if it is in global memory. If it is in
global memory, the request will be passed back down to IPX without
any virtualization. For example, a TSR loaded before Windows is
considered to be in global memory. If that TSR calls IPX, VIPX
will test the requests and pass them back down to IPX. This is
done because there is no need to virtualize requests that are
already global.
The use of UMA memory complicates the test for global memory.
There are two basic scenarios.
The first scenario is when a TSR has been loaded high before
Windows was loaded. In this case, IPX requests will come from
global UMA memory. VIPX will simply pass these requests back down
to IPX.
The second scenario is when a TSR is loaded high in a Windows
DOSBOX. In this case, IPX requests will come from local UMA
memory. VIPX will virtualize these requests.
Some memory managers test for global UMA memory and will work
properly under both scenarios. However, other memory managers
exist that do not work properly under Windows. With these drivers,
all local DOSBOX UMAs look as if they are GLOBAL UMAs.
In the case of the second scenario when a TSR calls IPX, VIPX will
test the request buffer and think that it is in global UMA memory
when it is really in LOCAL UMA memory. As a result, VIPX will pass
a local ECB to IPX without virtualization. The normal result of
this is a hung machine or data corruption.
SOLUTION
Novell strongly recommends that you update your dedicated IPX
driver with IPXODI.COM v2.12, included in DOSUP9 .EXE, when using
versions of VIPX later than 1.10.
Because of the problems with LSL.COM, Novell also recommends that
you update your LSL.COM to v2.05. This version is also available
in DOSUP9 .EXE in the NOVFILES forum of Compuserve.
If you are using third-party memory managers and hang, do not load
TSRs using the IPX interface (including IPX itself) high. Load
then in conventional memory only.
Files Needed: Size Date Version Location
VIPX.386 23855 10-08-93 1.17 WINUP9.EXE
IPXODI.COM 30247 10-07-93 2.12 DOSUP9 .EXE
LSL.COM 17805 09-10-93 2.05 DOSUP9 .EXE
Installation Instructions:
1. Rename or backup the old VIPX.386, IPXODI.COM, and LSL.COM
files.
2. Copy IPXODI.COM and LSL.COM to where the network board's
software is initialized.
3. Copy VIPX.386 to your WINDOWS\SYSTEM directory.
4. Virtualize the network board's IRQ in the [VIPX] section of the
SYSTEM.INI if using IBM LAN SUPPORT.
5. Put TimerCriticalSection=10000 in the [386Enh] section of the
SYSTEM.INI.
6. Download, and implement the VTDA.386 driver from MicroSoft.
7. Reboot the machine and load the ODI drivers.
8. Enter Windows.
Solution Specifics:
Specialized Configuration Parameters
------------------------------------
Under most circumstances, VIPX will work fine under the default
configuration. However, there may be some applications that
require custom configuration of the driver. This following is a
list of SYSTEM.INI parameters that can be used to configure VIPX:
[VIPX]
VipxMappingPages =[number of 4K pages] (default = 16)
VipxFailOverSizedPackets =[ON|OFF|TRUE|FALSE] (default = OFF)
VirtualizeIrq[0-F] =[ON|OFF|TRUE|FALSE] (default = OFF)
VIPX Parameters
VipxMappingPages
----------------
This is the number of pages that VIPX can use to globalize requests
to the global IPXODI.COM driver. VIPX is not absolutely guaranteed
to have all of these pages available at any one point, because this
is the requested number of pages for shared global mapping that
VIPX makes to the Windows VMM at initialization time.
VipxFailOverSizedPackets
------------------------
This parameter tells VIPX to fail any requests that require more
than the maximum allowed globalization size. The actual maximum
will vary according to the media the user is using. The absolute
maximum is 8000 (decimal) bytes. With media that have smaller
packets than 8000 bytes, the maximum allowed size is the maximum
packet size that can be put onto the media.
VirtualizeIrq[0-F]
------------------
VIPX v1.15 or greater avoids a deadlock between the machine and
network board by virtualizing the network board's IRQ. With ODI
and dedicated IPX (IPX.OBJ) drivers, VIPX will automatically read
the configuration of the network board from the driver and
virtualize the selected IRQs. However, when using the IBM LAN
Support Program with SLANSUP.OBJ or LANSUP.COM, the LAN IRQ is not
readable from the driver. The only way to get this information is
to read the network board hardware itself. The problem with doing
this is that the hardware can be Token Ring, PCN2 or Ethernet.
VIPX must now be aware of many different hardware configurations.
Instead of this, VIPX requires the IBM LAN Support user to specify
the network board's IRQ in the [VIPX] section of the SYSTEM.INI.
IRQs range from 0 to F (hex). An example is listed below:
[VIPX]
VirtualizeIrq2=TRUE
VirtualizeIrq3=TRUE
In this example, VIPX will virtualize both IRQ 2 and IRQ 3. VIPX
can virtualize up to four different LAN IRQs. The reason for
virtualizing multiple IRQs is to allow other LAN boards and
protocols to be installed on the same PC and prevent them from
deadlocking the machine. For example, you may have IPX running
through an NE2000 board on IRQ 3 and TCP/IP running through to an
IBM Token-Ring board on IRQ 2.
TimerCriticalSection
--------------------
As of version 1.15 of VIPX, TimerCriticalSection is required to be
set on. The recommended setting is as follows:
[386Enh]
TimerCriticalSection=10000
The reason for this parameter is to avoid a deadlock with the LAN
IRQ Virtualization code. See "VirtualizeIrq[0-F]" section.
Changes to LSL.COM v2.05
1. GetStackECBPrescanIsPresent destroyed the return Flag when an
ECB was given. The symptom of this problem would most likely
manifest it self by a workstation hang when using a protocol stack
that expects to get an ECB from the LSL under a heavy load.
2. Added a line to correct ECBLISTHEAD overwriting of variable
StackECBHoldQHead.
Changes to LSL.COM v2.02
1. Commandline Switches:
Valid switches: U, F, ?, H, C=
Only the "U, ?, C=" are documented in the help.
U Used to unload LSL.
? Used for Help.
F Used to force the unload.
H Used as an equivalent to "?" switch, and is used by
many of Novell's other utilities.
C= Used to change the path or filename of the configuration
file. The "C=" switch is the only two-letter switch that is
valid, Custom Configuration Files. When using the "C="
command-line switch, the LSL first tries the
[path]\filename as given. If the file is not found, then
the filename is searched for in the directory where the LSL
was loaded from; and if it still cannot be found, it looks
in the current working directory. If all these efforts
fail, then the LSL reverts back to looking for a "NET.CFG"
file in the directory where the LSL was loaded from then in
the current working directory. The filename is considered
valid even if the path was incorrect. After parsing the
Configuration file, the LSL displays the relative path of
the Configuration file that was parsed.
2. LSL.COM had a number of bugs and one was a bug that caused a
deadlock situation with the LAN adapter. A Do Send for Windows
needed a Start and End Critical Section call added. It is now
language enabled.
3. Multiple Prescan Stack Chaining did not pass a packet properly.
4. GetProtocolControlEntry would not return the DefaultProtocol
Control Entry point if it was not the only stack in the
DefaultProtocolChain.
5. Bound checking was added on the MLID Support Functions.
6. Error code not preserved in Deregister Prescan Tx chain.
7. A bug in Memory Calculation when calculating the amount of
memory to reserve when going TSR was fixed.
8. The LSL, while checking for boards and Protocols that were still
registered would unload from memory, leaving the still registered
entities with bad pointers. The LSL will now remove all the MLIDS,
through the SHUTDOWN command. The LSL will not unload if a
Protocol stack is still registered with the LSL.
9. On Installation of a LAN driver, the LSL would check the version
of the Configuration Table and delete the board number. This is
now fixed.
10. On unload of a LAN driver, the driver called
MLIDSUP_DEREGISTER_MLID, which called MLIDSUP_CONTROL_STACK_FILTER.
When testing for board numbers that are bound to the MLID, a JNE
was used where a JE was needed.
IPXODI.COM
Command line Switches:
Valid switches: /?, /D, /A, /C=, /U, /F
? Used for help screen.
D Used for Eliminate Diagnostic Responder; reduces size
by 3 KB.
A Used for Eliminate Diagnostic Responder and SPX;
reduces size by 9 KB.
PLEASE NOTE: Disabling SPX will mean that SPX
applications (such as RPRINTER, BTRIEVE, RCONSOLE, or
Netware for SAA STRNRTR) will not be supported on this
workstation.
C= Used to change the path or filename of the
configuration file. "C=" is the only two letter switch
that is valid. If the *.CFG file used does not exist a
message will be displayed that the standard NET.CFG
file will be used instead.
U Used to unload.
F Used to force the unload.
IPXODI.COM v2.12 Released for NetWare 4.01 Update
1. Fixed SPX problem that was seen using NASI/NACS modem sharing
data. This problem shows up when using an SPX applications that is
transferring data in full duplex mode (most SPX applications do not
do this). The code was advancing the session sequence number in
the local session table immediately after sending an SPX data
packet to the other side. If a data packet came in from the other
side that did not acknowledge Novell's "send," Novell would
generate a system packet back to the other end with the session
sequence number set to the value in the local session table, which
is one higher than what it should be. Then if Novell's data packet
got dropped, Novell would retransmit it, in which case the other
end would ignore our packet since it session sequence number was
not high enough. This would result in session failure.
2. Enhanced initialization code to check the board's node ID for
all 0FFs. If it is then we display an error and fail to load.
This enhancement was requested by Novell Austin for support of his
serial line ODI drivers which set the node Id to all 0FFs if the
user hasn't made a connection. A new error message has been
created for this condition, however the code checks to see if the
msg file IPXODI is using has the new error message. If it does
not, then the error condition is ignored and IPXODI still loads.
This will allow current/older msg files to be used successfully.
3. A problem in RxHandler was fixed that was introduced in IPXODI
v2.00 where in the case Novell steals a mapping ECB then they have
to have VIPX get a client receive ECB. Novell was not preserving
register AX, which was supposed to have the destination socket
number. In this case, VIPX would return that there was not any
receive ECB since it thought the socket was not opened when in
reality it was and it had receives posted. This bug can cause
back-to-back receive packets to be dropped when the packets are
destined for an IPX application (DOS or Windows) running under
Enhanced mode Windows.
4. Novell fixed IPX diagnostic responder code so it would return a
0FFFFh in the SPX socket number field of the IPX diagnostic query
reply packet when SPX or diagnostic portion of IPXODI has not be
loaded by the user. This provides a method for diagnostic
applications to determine if SPX is there or not so they do not
have to attempt a SPX connect request if SPX is not there.
IPXODI.COM 04-23-93 v2.11 Released for NMS and NetWare 4.01
Release
1. Implemented fix in SPX.ASM SPXConnectHandler routine where it
was not preserving the session count in CX when comparing the
session addresses. This problem exists in the dedicated IPX/SPX
module as well. To see this problem the same source connection ID
would have to be in use by two nodes trying to connect to a
particular node.
2. Novell fixed a bug in SPXMessageHandler routine where it was
setting the a send ECB's ESR to SessionSendCompletedDelayed without
a group "CGroup:" override that caused a bogus offset to be put in
the ESR offset field. Thus when the active send finished it would
blow up. This problem exists in the dedicated IPX/SPX module as
well. This problem showed itself while running the Novell NMS
Windows application for a few hours.
3. IPXODI.COM had a bug in SPX. During a retry, SPX would jump to
invalid memory causing an invalid opcode exception in v86 mode only
when SPX is being used. Few applications use SPX. This usually
manifests itself as a reboot, hung machine, or blank screen with
cursor in upper-left corner.
